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(57) An apparatus, program product and method uti- 
lize a displayed pictorial representation that depicts the 
actual physical configuration of a plurality of hardware 
components in a physical computer system to facilitate 
the collective management of the underlying hardware 
components. Typically, within such a pictorial represen- 
tation, a selected status is displayed for multiple of such 
hardware components, thereby permitting hardware 
components sharing common attributes or characteris- 
tics to be identified in an efficient and intuitive manner, 
as well as to permit collective management operations 
to be performed on all selected hardware components. 



In addition, a pictorial representation may be dynami- 
cally generated to represent the physical configuration 
of a plurality of hardware components within a plurality 
of computers. In connection with such dynamic gener- 
ation, the plurality of computers may be accessed to 
identify the plurality of hardware components that are 
resident in such computers. Moreover, management op- 
erations may be performed on selected hardware com- 
ponents in response to user input directed to those por- 
tions of the pictorial representation that represent the 
physical configurations of such selected hardware com- 
ponents. 
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Description 

Field of the Invention 

[0001] The invention is generally related to computers 
and computer softw^are. More specifically, the invention 
is generally related to user interfaces for use in manag- 
ing computer hardware components. 

Background of the Invention 

[0002] Graphical user interfaces (GUI's) have been 
used with great success to simplify and enhance user 
interaction with computers. In a GUI environment, a 
combination of text and graphical objects are displayed 
on a computer display with a user able to interact with 
various objects predominantly through "pointing and 
clicking" with a user-manipulated pointer controlled by 
a mouse or similar device. GUI environments are often 
highly intuitive, as a user is able to perform a desired 
action on a particular object simply by pointing at the 
object and initiating a desired action. For example, if a 
user wants to see the files stored on a particular disk 
drive accessible via a computer, the user may be per- 
mitted to point and click on an icon that represents the 
disk drive, resulting in the display of a window that lists 
the drive contents. 

[0003] One area in which GUI's have been employed 
is that of hardware component management. Hardware 
component management is used to manage (i.e., to 
configure and/or obtain status information about) hard- 
ware components in a computer or computer system. 
Conventional GUI environments often permit users, for 
example, to select icons associated with particular hard- 
ware components to perform management operations 
on the underlying components. For example, in a GUI 
environment a user may be permitted to pull up a con- 
text-sensitive menu by selecting a disk drive icon to per- 
form operations such as formatting the disk drive asso- 
ciated with the icon. Also, dialog boxes may be ac- 
cessed via icons to perform more advanced configura- 
tion operations on underlying hardware components. In 
some instances, hardware components may even be 
grouped together into a "control panel" window or a tree- 
like representation where icons are arranged hierarchi- 
cally and grouped by type, e.g., where multiple disk 
drives are grouped together under a "disk drive" head- 
ing. 

[0004] While GUI-based component managers offer 
substantial usability improvements over older, more 
cumbersome text-based component managers, most 
such GUI-based component managers have been 
found to be somewhat limited in the ability to inform a 
user of the underlying physical configuration of a hard- 
ware component within a computer system — specifical- 
ly where in a computera particular hardware component 
is physically located. Management of a computer or 
computer system often incorporates more than simple 



software configuration; oftentimes a user is required to 
physically access hardware components to effectively 
manage the overall system. 

[0005] Conventional GUI-based component manag- 
5 ers typically identify the location of a hardware compo- 
nent by identifying the slot or port to which such a com- 
ponent is connected. Looking at the actual computer, 
however, specific slots or ports may be difficult to locate, 
and a user may have difficulty in physically locating spe- 
*o cific hardware components in the computer. 

[0006] Moreover, this problem is significantly greater 
in complex multi-unit computer systems such as serv- 
ers, midrange computers and mainframe computers, 
where the number of manageable hardware compe- 
ls nents can be overwhelming. For example, some enter- 
prise-level storage systems are capable of housing hun- 
dreds of individual disk drives in large physical enclo- 
sures, and simply providing a user with a slot location 
in an enclosure for a particular disk drive may still leave 
20 the user with the daunting taskof locating that particular 
slot among hundreds in the physical enclosure. In short, 
there is little information provided in conventional GUI 
environments that interrelates the logical location of a 
hardware component (i.e., with respect to the overall 
25 logical or software organization of a computer) with the 
physical location of the hardware computer in the com- 
puter. 

[0007] In some GUI environments, a displayed picto- 
rial representation of a computer has been used to a 

30 limited extent to facilitate management of hardware 
components in the computer. For example, one conven- 
tional GUI environment for a laptop computer displays 
a pictorial representation of the laptop computer, with 
icons associated with various external devices capable 

35 of being connected to the computer disposed around the 
periphery of the pictorial representation and visually 
linked to specific external ports on the computer by lines 
extending from the icons to the depictions of the ports 
on the pictorial representation of the computer. Manage- 

40 ment of the underlying hardware components is per- 
formed using the icons, and is limited to interaction via 
singular icons, and to hardware components located on 
a single computer. Furthermore, such an environment 
is typically statically defined for a particular computer 

45 design, as the environment is based principally on the 
ports, rather than the devices that could be connected 
to those ports. 

[0008] Despite the additional information with regard 
to physical location that is provided by the display of a 

50 pictorial representation in the aforementioned GUI en- 
vironment, for more complex managed environments, 
where potentially hundreds of hardware components 
need to be managed, a significant need still exists for 
greater flexibility and usability in terms of GUI-based 

55 hardware component management. Therefore, a need 
continues to exist in the art for a GUI-based hardware 
component management environment offering greater 
usability, flexibility and functionality than conventional 
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GUI-based environments. 
Summary of the Invention 

[0009] The invention mitigates the problems associ- 
ated with the prior art by providing an apparatus, pro- 
gram product and method in which a displayed pictorial 
representation that depicts the actual physical configu- 
ration of a plurality of hardware components in a phys- 
ical computer system is utilized for facilitating the col- 
lective management of the underlying hardware compo- 
nents. In particular, within such a pictorial representa- 
tion, a selected status Is displayed for multiple of such 
hardware components. Such a configuration permits, 
for example, hardware components sharing common at- 
tributes or characteristics to be identified in an efficient 
and intuitive manner. In addition, such a configuration 
permits, for example, collective management opera- 
tions to be performed on all selected hardware compo- 
nents, thus facilitating hardware management tasks 
where multiple components need to be configured in the 
same manner, and without requiring that each such 
component be configured via a separate operation. 
[0010] In another aspect, a pictorial representation 
may be dynamically generated to represent the physical 
configuration of a plurality of hardware components 
within a plurality of computers. In connection with such 
dynamic generation, the plurality of computers may be 
accessed to identify the plurality of hardware compo- 
nents that are resident in such computers. Moreover, 
management operations may be performed on selected 
hardware components in response to user input direct- 
ed to those portions of the pictorial representation that 
represent the physical configurations of such selected 
hardware components. 

Brief Description of the Drawings 

[0011] Preferred embodiments of the invention will 
now be described in more detail, by way of example, 
with reference to the accompanying drawings in which: 

FIGURE 1 is a block diagram of a computer system 
consistent with the invention. 

FIGURE 2 is a block diagram of an exemplary hard- 
ware and software environmentfora managercom- 
puter from the computer system of Fig. 1 . 

FIGURE 3 is a block diagram illustrating a logical 
organization of objects in a GUI framework resident 
in the manager computer of Fig. 2. 

FIGURE 4 is a flowchart illustrating the program 
flow of startup and display update routines execut- 
ed by the component manager resident in the man- 
ager computer of Fig. 2. 



FIGURE 5 is a block diagram of an exemplary pic- 
torial view window generated by the startup and dis- 
play update routines of Fig. 4. 

5 FIGURE 6 is a flowchart illustrating the program 

flow of a select/deselect routine executed by the 
component manager resident in the manager com- 
puter of Fig. 2. 

10 FIGURE 7 is a flowchart illustrating the program 
flow of a focus routine executed by the component 
manager resident in the manager computer of Fig. 

2. 

15 FIGURE 8 is a flowchart illustrating the program 
flow of a display context menu routine executed by 
the component manager resident in the manager 
computer of Fig. 2. 

20 FIGURE 9 is a flowchart illustrating the program 
flow of a perform action routine executed by the 
component manager resident in the manager com- 
puter of Fig. 2. 

25 FIGURE 10 is a block diagram of the exemplary pic- 
torial view window of Fig. 5, subsequent to display 
of a context menu and initiation of an action on se- 
lected hardware components. 



[0012] The embodiments described hereinafter may 
be used to enhance the ability of a user to effectively 
manage hardware components in a computer system 

35 through the use of a unique interactive pictorial display 
that pictorially represents the actual physical hardware 
configuration of one or more computers in a computer 
system. Consistent with the invention, such a pictorial 
display may be used to configure and manage hardware 

40 components on a local computer (i.e., on the same com- 
puter that is being managed) or on a remote computer 
(i.e., coupled to the managing computer over a network 
or other electronic interface). 

[0013] For example, Fig. 1 of the Drawings, wherein 
45 like numbers denote like parts throughout the several 
views, illustrates a computer system 10 implementing 
pictorial-based computer hardware component man- 
agement consistent with the invention. Computer sys- 
tem 10 includes a manager computer 12 coupled to a 
50 network generically represented at 14. Consistent with 
the invention, manager computer 12 may implement 
pictorial-based hardware component management of 
hardware components resident in the manager compu- 
ter itself, or to one or more other remote computers or 
55 electronic devices in computer system 10, e.g., a single- 
user computer 16, a single-unit multi-user computer 18 
such as a minicomputer or server, a multi-unit multi-user 
system incorporating a computer 20 and one or more 
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supplemental hardware units (e.g., storage towers 22), 
or even a clustered system 24 Including a plurality of 
cluster nodes 26. 

[0014] From the illustration in Fig. 1, it will be apparent 
to one of ordinary skill in the art having the benefit of the 
instant disclosure that pictorial-based hardware compo- 
nent management may be used to manage practically 
any electronic device incorporating configurable and/or 
manageable hardware components. In addition, it will 
be appreciated that the precise manner in which a man- 
aging device and a managed device are interconnected 
(both with respect to hardware and software interfaces) 
may vary in different applications. For example, network 
14 may represent practically any type of networked in- 
terconnection, including but not limited to local-area, 
wide-area, wireless, and public networks (e.g., the In- 
ternet), point-to- point serial or parallel interconnects, 
etc. 

[0015] Fig. 2 illustrates an exemplary hardware and 
software environment for a manager computer or appa- 
ratus 30 consistent with the invention. For the purposes 
of the invention, apparatus 30 may represent practically 
any type of single- or multi-user computer, computer 
system or other programmable electronic device, in- 
cluding a client computer, a server computer, a portable 
computer, a handheld computer, an embedded control- 
ler, etc. Apparatus 30 may be coupled in a network as 
shown in Fig. 1 , or may be a stand-alone device in the 
alternative. Apparatus 30 will hereinafter also be re- 
ferred to as a "computer", although it should be appre- 
ciated the term "apparatus" may also include other suit- 
able programmable electronic devices consistent with 
the invention. 

[0016] Computer 30 typically includes at least one 
processor 31 coupled to a memory 32. Processor 31 
may represent one or more processors (e.g.. microproc- 
essors), and memory 32 may represent the random ac- 
cess memory (RAM) devices comprising the main stor- 
age of computer 30, as well as any supplemental levels 
of memory, e.g., cache memories, non-volatile or back- 
up memories (e.g., programmable or flash memories), 
read-only memories, etc. In addition, memory 32 may 
be considered to include memory storage physically lo- 
cated elsewhere in computer 30, e.g., any cache mem- 
ory in a processor 31, as well as any storage capacity 
used as a virtual memory, e.g., as stored on a mass stor- 
age device 35 or on another computer coupled to com- 
puter 30 via network 36. 

[0017] Computer 30 also typically receives a number 
of inputs and outputs for communicating information ex- 
ternally. For interface with a user or operator, computer 
30 typically includes one or more user input devices 33 
(e.g., a keyboard, a mouse, a trackball, a joystick, a 
touchpad, and/or a microphone, among others) and a 
display 34 (e.g., a CRT monitor, an LCD display panel, 
and/or a speaker, among others). For additional stor- 
age, computer 30 may also include one or more mass 
storage devices 35, e.g., a floppy or other removable 



disk drive, a hard disk drive, a direct access storage de- 
vice (DASD), an optical drive (e.g., a CD drive, a DVD 
drive, etc.), and/or a tape drive, among others. Further- 
more, computer 30 may include an interface with one or 

5 more networks 36 (e.g., a LAN, a WAN, a wireless net- 
work, and/or the Internet, among others) to permit the 
communication of information with other computers 
coupled to the network. It should be appreciated that 
computer 30 typically includes suitable analog and/or 

10 digital interfaces between processor 31 and each of 
components 32, 33, 34, 35 and 36 as is well known in 
the art. 

[0018] Computer 30 operates under the control of an 
operating system 38, and executes or otherwise relies 
15 upon various computer software applications, compo- 
nents, programs, objects, modules, data structures, etc. 
(e.g., GUI framework 40 and component manager 42, 
among others). Moreover, various applications, compo- 
nents, programs, objects, modules, etc. may also exe- 

20 cute on one or more processors in another computer 
coupled to computer 30 via a network 36, e.g., in a dis- 
tributed or client-server computing environment, where- 
by the processing required to implement the functions 
of a computer program may be allocated to multiple 

25 computers over a network. 

[0019] In general, the routines executed to implement 
the embodiments of the invention, whether implement- 
ed as part of an operating system or a specific applica- 
tion, component, program, object, module or sequence 

30 of instructions will be referred to herein as "computer 
programs", or simply "programs". The computer pro- 
grams typically comprise one or more instructions that 
are resident at various times in various memory and 
storage devices in a computer, and that, when read and 

35 executed by one or more processors in a computer, 
cause that computer to perform the steps necessary to 
execute steps or elements embodying the various as- 
pects of the invention. Moreover, while the invention has 
and hereinafter will be described in the context of fully 

40 functioning computers and computer systems, those 
skilled in the art will appreciate that the various embod- 
iments of the invention are capable of being distributed 
as a program product in a variety of forms, and that the 
invention applies equally regardless of the particular 

15 type of signal bearing media used to actually carry out 
the distribution. Examples of signal bearing media in- 
clude but are not limited to recordable type media such 
as volatile and non-volatile memory devices, floppy and 
other removable disks, hard disk drives, magnetic tape, 

50 optical disks (e.g., CD- ROM's, DVD's, etc.), among oth- 
ers, and transmission type media such as digital and an- 
alog communication links. 

[0020] In addition, various programs described here- 
inafter may be identified based upon the application for 
55 which they are implemented in a specific embodiment 
of the invention. However, it should be appreciated that 
any particular program nomenclature that follows is 
used merely for convenience, and thus the invention 
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should not be limited to use solely in any specific appli- 
cation identified and/or innplied by such nomenclature. 
[0021] Those skilled in the art will recognize that the 
exemplary environments illustrated in Figs. 1 and 2 are 
not intended to limit the present invention, indeed, those 
skilled in the art will recognize that other alternative 
hardware and/or software environments may be used 
without departing from the scope of the invention. 

Pictorial-Based Hardware Component Management 

[0022] In the illustrated embodiment described here- 
inafter, pictorial-based hardware component manage- 
ment is implemented within a graphical user interface 
(GUI) framework implemented via a plurality of objects, 
e.g., as illustrated at 50 In Fig. 3. An object tree repre- 
senting the GUI framework is accessible via a root node 
52 from which one or more system objects 54 are refer- 
enced. Each system object represents a particular com- 
puter or computer system accessible via a manager 
computer for performing component management 
therewith. Typically, each system object will represent a 
computer or other electronic unit within which multiple 
hardware components are mounted or are otherwise 
resident. As such, each system object may represent, 
for example, a stand-alone computer, a multi-user conn- 
puter, a clustered system, or even individual expansion 
towers or chassis in which hardware components may 
be mounted. 

[0023] Each system object includes, among other da- 
ta, a diagram list 56 that references one or more diagram 
objects 60. Each diagram object 60 in turn includes an 
image 62 and an item mapping 64. 
[0024] Each diagram object represents a distinct pic- 
torial representation of the computer or computer sys- 
tem referenced by the associated system object 54. It 
should be noted that multiple diagrams may be support- 
ed for each system object, with the multiple diagrams 
providing different viewpoints, e.g., different sides, lay- 
ers, elevations, levels of zoom, etc. The image data 62 
associated with each diagram object represents the ac- 
tual image data (or a pointer to the location of such data) 
that will be displayed on a computer display to pictorially 
depict the associated view of the represented system. 
[0025] An image may provide a pictorial representa- 
tion in a number of manners, including two or three di- 
mensional representations, as well as a variety of image 
types that pictorially represent the actual physical con- 
figuration of hardware components within the associat- 
ed system. Images may be photographic in nature, or 
may be diagrammatic, e.g., lined and/or shaded draw- 
ings representative of the physical configuration of a 
computer. Moreover, diagrams may be in color, gray 
scale or black and white. Any other image type that ac- 
curately depicts the relative placement and location of 
hardware components within a computer may be used 
in the alternative. Images may represent external views 
of a system and/or may represent interna! views within 



a system. Images may also be comprised of multiple lay- 
ers that are selectively shown or hidden based upon the 
types of hardware components of interest. 
[0026] Diagrams and in particular image information 

5 therefor may be provided from a number of sources. For 
example, such information may be resident in a compu- 
ter or computer system when shipped. In the alternative, 
such information may be retrieved from an external 
source, e.g., over a network such as the Internet. Doing 

10 so would permit, for example, a query to be made from 
a central repository based on a model number or other 
identifier associated with a particular computer, compu- 
ter system, or even individual hardware components, 
with pictorial and/or other information downloaded to the 

15 manager computer as needed to provide the appropri- 
ate pictorial information for all of the computers/compu- 
ter systems capable of being managed by the manager 
computer. As such, were a system operator to add a new 
computer or component to be managed by an estab- 

20 iished manager computer, such a query could be used 
to obtain up-to-date pictorial information for the new 
computer or component. Moreover, in other embodi- 
ments, pictorial information may be provided with par- 
ticular hardware components, computers, computer 

25 systems, etc., e.g., along with drivers or other support 
software therefor. Doing so would permit, for example, 
pictorial information to be automatically installed in con- 
nection with the installation of an upgraded component 
or computer to a managed system. 

30 [0027] The item mapping for each diagram 60 points 
to one or more item objects (e.g., item 70) representa- 
tive of the various hardware components accessible via 
a diagram object 60. Given that each diagram object 
identifies the physical configuration and location of a 

35 hardware component within the associated image, item 
mapping 64 also typically includes mapping data that 
identifies where on the associated image a particular 
hardware component is depicted. As discussed below, 
such mapping data enables both pictorial representa- 

40 tions of hardware components to be selectively high- 
lighted, and user input directed to a particular hardware 
component to be identified within an image. 
[0028] Each item object 70 includes a highlight indi- 
cator or flag 72 indicating whether the associated item 

45 should be highlighted to represent a selected status of 
or to represent a particular filter selection criterion for 
the associated hardware component. In addition, each 
item object includes one or more attributes for the un- 
derlying hardware component for use in performing fil- 

50 tering or searching of hardware components in a man- 
ner discussed below. Attributes may provide class or 
type information about practically any physical, electri- 
cal or logical characteristic of the associated hardware 
component. For example, for a disk drive hardware 

55 component, attributes may be used to indicate the fact 
that the device is a disk drive, the capacity, the amount 
of free space, the interface type, the speed, the mem- 
bership of the component in a pool or other grouping of 
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multiple components (e.g., a backup group, a mirrored 
pair, etc.), the compressed status, the balanced status, 
the location, the model, the serial number, the configu- 
ration settings, etc. For other types of hardware compo- 
nents, the types of attributes stored in the associated 
item object will, of course, vary. 

[0029] A predominant function of each item object 70 
is to operate as a "wrapper" to the actual management 
interface for the associated hardware component, rep- 
resented in Fig. 3 by component object interface 76. 
[0030] It will be appreciated by one of ordinary skill in 
the art having the benefit of the instant disclosure that 
software management of hardware components is well 
known in the art, and may be implemented through a 
standardized object-oriented interface through which 
status information may be obtained from hardware com- 
ponents, and desired management operations may be 
performed on such components. One such object-ori- 
ented management interface is used, for example, in the 
AS/400 midrange computer available from International 
Business Machines Corporation. Moreover, through the 
use of polymorphism, a common interface can typically 
be provided to a wide variety of different types of hard- 
ware components, with the specific functionality re- 
quired to interact with a particular type of hardware com- 
ponent hidden from higher layers of software, typically 
within a driver. As an example, conventional hardware 
management would permit an action such as "format 
drive" to be initiated on a wide variety of different types 
of disk drive hardware components, despite the fact that 
the underlying commands that may be expected by 
each disk drive may vary in implementation. Therefore, 
the provision of a generic component object to interface 
as illustrated in Fig. 3 would be well understood by one 
of ordinary skill in the art having the benefit of the instant 
disclosure. 

[0031] Therefore, each item object is capable in initi- 
ating actions on an underiying hardware component. 
Moreover, each item object is permitted to access status 
or state information from a hardware component, as well 
as to obtain a list of available actions from such a com- 
ponent so that the hardware manager is able to deter- 
mine what actions are appropriate for a given hardware 
component through a generic component-independent 
interface. 

[0032] Each item object 70 may also optionally in- 
clude one or more image overlays that could be utilized 
to generate a composite image with the underiying dia- 
gram to represent the current configuration of a compu- 
ter system. For example, a disk drive item object may 
include an image of the outer casing of the disk drive, 
with the underlying diagram on the associated diagram 
object displaying an empty disk drive slot, such that 
when a disk drive is present in the system, the image 
presented to a user will include the image of the disk 
drive casing overlaying the empty slot in the overall di- 
agram of the computer. 

[0033] Fig. 3 further illustrates a number of optional 



characteristics of a GUI framework that may be used to 
expand the functionality of the framework to encompass 
a wider variety of types of hardware components. For 
example, item object 80 illustrates a container-type ob- 
5 ject representing a hardware component such as a slot 
or port within which other hardware components may be 
mounted or attached. Therefore, in addition to a high- 
light indicator 82 and a set of attributes 84, container 
item object 80 includes a list of contents 86 that refer- 

10 ence the components (e.g., item object 88) that are 
mounted within the designated container. By supporting 
the hierarchical arrangement of hardware components 
to incorporate one or more layers of intermediate con- 
tainers, hardware components may be arranged into hi- 

^5 erarchica! levels to provide a more accurate represen- 
tation of the logical organization of hardware compo- 
nents in a computer system. As an example, a disk drive 
may be housed In a slot within a rack of slots in a tower 
enclosure. Thus, individual item objects could be used 

20 for the disk drive, slot, rack and enclosure to provide 
separate management of the hardware at each level of 
detail. 

[0034] Moreover, by providing container objects sep- 
arate from the item object for the hardware components 

25 that are mounted therein, component management of 
the actual containers may be performed (if appropriate). 
Therefore, for example, a slot or port- type container ob- 
ject could be used to configure a slot or port independent 
of the hardware component mounted therein. Moreover, 

30 if a slot, port or other interface component is currently 
unused (i.e., no other items are pointed to by the con- 
tents 86), the underiying component may still be config- 
ured via the component manager, and moreover, a user 
may be permitted to perform actions such as locating all 

35 empty interface components of a given type through the 
GUI framework, installing a component in an unused in- 
terface component, etc. 

[0035] Item object 88 also illustrates an additional but 
optional concept, where item objects may be referenced 

40 by multiple diagram object 60. For example, if two dia- 
gram objects represent different levels of zoom of the 
same view of a computer, the same item object may be 
accessible via either diagram. Moreover, if the same 
hardware component is viewable from multiple sides of 

"5 a computer, the same item object may be utilized to ac- 
cess the underlying hardware component represented 
in diagrams representing such multiple sides. 
[0036] Fig. 3 also illustrates a filter selection criteria 
object 90 that identifies one or more filter criteria used 

50 to control the display of the pictorial representation re- 
sponsive to user input. Object 90 may include a current 
filter criterion, as well as one or more preset filter criteria 
such as an initial criterion, as well as any additional cri- 
teria stored by a user and representing different "views" 

55 of the hardware components capable of being managed 
by the component manager. 

[0037] It will be appreciated that other object-oriented 
frameworks may be utilized in other environments. 
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Moreover, other programming models, including non- 
object- oriented programming models, may also be 
used to implement pictorial-based component manage- 
ment consistent with the invention. Therefore, the inven- 
tion is not limited to the particular implementation dis- 
cussed herein. 

[0038] Figs. 4 and 6-9 illustrate a number of routines 
executed by component manager 42 of Fig. 2 to imple- 
ment interactive pictorial-based component manage- 
ment consistent with the invention. 
[0039] One important aspect of such management is 
the ability to dynamically generate a pictorial represen- 
tation based upon which hardware components are ac- 
cessible to the component manager. As such, in some 
embodiments the component manager may not need to 
be configured specifically for a particular type of system 
and set of hardware components, which is an important 
benefit given the fact that different computer installa- 
tions may have a wide variety of hardware configura- 
tions, and moreover, the fact that the hardware config- 
uration of a computer installation may change over time 
as components are added or upgraded. 
[0040] Fig, 4 illustrates at 100 a startup routine that 
may be executed during startup of a component man- 
ager to dynamically generate a pictorial representation 
consistent with the invention. Routine 100 begins at 
block 1 02 by determining a list of the systems to be rep- 
resented in a pictorial representation. In the alternative, 
if component management Is being performed for the 
local computer upon which the component manager is 
resident, block 102 may not be required. Otherwise, the 
component manager typically attempts to connect with 
various systems represented in the system objects of 
GUI framework 50 to determine what systems are ac- 
cessible and capable of being managed. It should also 
be appreciated that In instances of a component man- 
ager being unable to communicate with a remote com- 
puter, any Inaccessible systems may be omitted from 
the system list generated in block 102. 
[0041] Next, block 104 connects to each available 
system to determine the configuration and status of that 
system. In the illustrated embodiment, for example, it is 
desirable for each system to return a list of diagram ob- 
jects 60 (or pointers thereto), as well as the underlying 
item objects 70 referenced by such diagrams. In some 
embodiments, any or all of the objects 54, 60 and 70 
may be downloaded to the local computer upon which 
the component manager is executing, or any of such ob- 
jects may be maintained on remote systems with remote 
communication (e.g., remote procedure calls) used to 
implement the functionality described herein on the re- 
mote computer. As such, upon completion of block 104, 
the component manager is capable of determining what 
diagrams are accessible, as well as what hardware 
components are represented within each diagram. Inv 
plementation of an appropriate protocol to effect such 
polling by the component manager may take a number 
of forms, and would be within the abilities of one of or- 



dinary skill in the art having the benefit of the instant 
disclosure. 

[0042] Next, block 106 obtains the diagram images for 
each system In the system list. As an additional step in 
5 this operation, the diagram images may be assembled 
into a composite Image as appropriate and placed Into 
a window or other display panel on a computer display. 
[0043] Next, block 106 sets the current filter criterion 
to an Initial criterion, representing the initial display to 

10 be presented to a user. Based upon the initial filter cri- 
terion, a filter routine 110 is called, which begins In block 
112 by filtering Items from the systems In the systems 
list based upon the filter criterion. The highlight indicator 
or flag In each Item is set or cleared as appropriate to 

15 indicate which items meet or do not meet the selected 
filter criterion. For example, an initial filter criterion might 
be "show all disk drives", whereby block 112 would 
search through each accessible Item object to Identify 
items having attributes that Indicate that such items are 

20 associated with disk drives. Any such items would then 
be updated to a selected status by setting the highlight 
flag associated therewith. Other items, on the other 
hand, would be set to unselected status by virtue of 
clearing the highlight flags associated therewith. 

25 [0044] Once the Items have been filtered, control 
passes to block 114 to determine whether a "hide un- 
used diagrams" option Is set, indicating whether only di- 
agrams associated with selected Items should be dis- 
played. In other embodiments, unused diagrams may 

30 never be omitted, or may always be omitted. Moreover, 
the enabling or disabling of such a feature may be made 
in response to user input, or may be associated with a 
particular filter criterion. 

[0045] If unused diagrams should be hidden, control 
35 passes to block 116 to remove any unused diagram - 
typically by searching through each diagram to locate 
any diagram for which none of the dependent items 
linked to that diagram are selected. Control then passes 
to block 118 to create a mapping of all matching items 
40 on the diagram images. Moreover, if unused diagrams 
are not to be hidden, block 114 passes control directly 
to block 118. 

[0046] Block 118 creates a mapping by accessing the 
Item mapping Information in each diagram object, which 
15 establishes the extents of the depictions associated with 
the matching or selected items on the diagram images, 
thereby defining "hot spots" on the diagrams associated 
with the selected items. In the alternative, mappings 
may be made of all available items regardless of select- 
so ed or unselected status, such that a user may interact 
with any item regardless of whether It Is selected by the 
current filter criterion. Limiting user interaction to select- 
ed items, on the other hand, may be beneficial in many 
instances to simplify the user Interface. 
55 [0047] Next, block 120 displays the diagram Images 
with the matching or selected items highlighted on the 
display. Various manners of highlighting may be used, 
including, distinct colors, shadings, outlines, text fonts, 
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icon overlays, animation, etc. Control then passes to 
block 122 to determine whether the status or state of 
each item should be displayed on the pictorial represen- 
tation. If so, control passes to block 124 to update the 
diagram images with status and state information for 5 
each item, or alternatively, for each selected item only. 
Block 124 may also require that the component manag- 
er connect with the underlying hardware components 
associated with such items to obtain such status infor- 
mation. A determination of whether to show item status io 
may be made in response to user input, or may be as- 
sociated with a particular filter criterion. In the alterna- 
tive, the feature may be omitted, or may be permanently 
enabled in other embodiments. Providing the ability to 
display status information would permit, for example, a 15 
filter criterion to specify that the amount of free space 
associated with ail available drives be displayed in as- 
sociation with each selected drive, among a wide variety 
of other status information. Upon completion of block 
124, or if item states should not be displayed, routine 20 
100 is complete. 

[0048] As discussed above, a user may be permitted 
to selectively update the pictorial representation accord- 
ing to different filter criteria. For example, a user may 
wish to input a filter or search criterion, e.g., via a dialog 25 
box or other user input control, to perform different types 
of searches on the available hardware components. Al- 
so, In addition to the user input of search or filter crite- 
rion , a component manager may define one or more pre- 
determined "views" associated with particular filter cri- 30 
terion. For example, for a complex computer system, dif- 
ferent views may be defined to view different types of 
objects, e.g., disk drives, network adaptors, workstation 
controllers, etc., with unique filter criterion associated 
with each view, so that the same underiying GUI frame- 35 
work may be utilized to manage a wide variety of com- 
ponents in a customized manner. In this manner, the pic- 
torial representation in the underlying GUI framework 
may be considered to operate much as a computer 
"anatomy chart", analogous in many respects to a hu- 40 
man anatomy chart, where a user might be presented 
with different views of the same computer much in the 
same manner a user could look at the skin, muscles, 
arteries, veins, organs, nervous system of the body, with 
undesirable or irrelevant layers or components hidden 45 
in different views. Moreover, the additional ability to hide 
unused diagrams permits widely different views to be 
displayed based upon the context of what information a 
user is attempting to obtain. For example, a computer 
system may include a main unit and multiple disk tow- so 
ers, with multiple diagrams showing the different sides 
of each unit. However, through the use of appropriate 
filter criteria, if a user is looking at a particular pool of 
disk units, only one or a subset of the available towers 
may be displayed, while if a user desires only to access 55 
components in the main unit, all disk towers will be hid- 
den from view. It will therefore be appreciated that a 
great deal of flexibility is provided by the herein-de- 



scribed GUI framework. 

[0049] Regardless of the mechanism by which a new 
filter criterion is specified, the component manager also 
supports the ability to dynamically update the pictorial 
representation, as represented by routine 130 also 
shown in Fig. 4. Routine 130 begins in block 132 by 
clearing all highlight flags of the items in the GU I frame- 
work. Then, block 134 obtains a new filter criterion 
based upon user input - either via the selection of a pre- 
determined view, a stored search or filter criterion, or a 
manually-input search or filter criterion. Routine 130 
then calls filter routine 1 1 0 to apply the new filter criterion 
to the pictorial representation, whereby the above-de- 
scribed flow of routine 110 updates the pictorial repre- 
sentation as appropriate. 

[0050] Fig. 5, for example, illustrates an exemplary 
window 140 displayed on a computer display in repre- 
senting an exemplary pictorial representation 142 con- 
sistent with the invention. Pictorial representation 142 
may be generated, for example, byeitherof routines 100 
or 1 30, and represents a view of the disk units on a multi- 
user computer such as an AS/400 midrange computer 
available from International Business Machines Corpo- 
ration. In the exemplary pictorial representation, it is as- 
sumed that the computer system includes multiple disk 
towers, including a pair of towers designated herein as 
towers 1 and 2. Additional towers may also be present 
in the computer system, however, such towers may not 
include any selected hardware components, and thus 
may be omitted from the display. It may also be seen 
that each tower includes a pair of diagrams representing 
different views of the same tower. For tower 1 , diagram 
144 represents a front view, while diagram 146 depicts 
a left side view. Likewise, for tower 2, a diagram 148 
displays a front view, while a diagram 150 displays a left 
side view. A wide variety of hardware components are 
represented within each diagram as Illustrated at 154, 
with multiple of such hardware components being high- 
lighted or selected in the current view, as represented 
at 156a-156e. A pointer 160 is also illustrated, with a 
pop-up window 162 displayed to show the current status 
of hardware component 1 56c in response to the pointer 
moving over the hot spot defined for such component 
(discussed in greater detail below in connection with Fig. 
7). 

[0051] For the illustrative view, a pull-down menu 170 
is illustrated providing a user- selectable list of prede- 
termined views through which a user may view different 
pictorial representations of the available hardware com- 
ponents accessible via the component manager. The 
current view depicted in Fig. 5 is that of the disk units, 
and as such, only diagrams within which active disk 
units capable of being managed by the component man- 
ager are displayed. Moreover, it will be appreciated that 
window 140 may include additional information in asso- 
ciation with a pictorial representation to facilitate the 
component management of the disk units. For example, 
a table 172 may be displayed to display status informa- 
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tion regarding the various hardware components in the 
computer system. Table 172 categorizes disl< units into 
pools, and Fig. 5 illustrates via cursor 174 the selection 
of disk pool 1 so that the individual disk units defined in 
the logical disk pool are selected or highlighted as illus- 
trated at 156a- 156e. By virtue of the dynamic genera- 
tion capability of the pictorial-based component manag- 
er described herein, if a user selected "disk pool 2" from 
table 172, the filter criterion would define, at the mini- 
mum, that only components that are disk drives incor- 
porated into disk pool 2 should be highlighted. As such, 
the display would be dynamically updated to highlight 
those matching disk units associated with such disk 
pool. It will be appreciated that any number of user in- 
terface controls may be utilized to define or modify a par- 
ticularfilter criterion and thereby initiate the dynamic up- 
date of a pictorial representation consistent with the in- 
vention. 

[0052] It will be appreciated that in many instances, 
each diagram will predominantly depict a housing oroth- 
er enclosure within which hardware components, are 
mounted. For other embodiments, other surrounding 
hardware may be displayed consistent with the inven- 
tion. 

[0053] Figs 6-9 next illustrate a number of additional 
functions that may be accessible via the pictorial repre- 
sentation. For example, Fig. 6 illustrates a select/dese- 
lect routine 180 invoked with respect to a particular di- 
agram in response to user input directed to select or 
deselect a particular hardware component. For exam- 
ple, routine 180 may be initiated in response to a user 
clicking a mouse button while the mouse is disposed 
over a particular hot spot associated with an item on a 
particular diagram. Routine 180 begins in block 182 by 
clearing any existing item highlight flags, if necessary. 
Next, block 184 determines the item that was selected 
on the diagram based upon the item map associated 
with the diagram. Block 186 then sets or clears the item 
highlight flag associated with the item as appropriate, 
and block 188 updates the diagram to reflect the new 
highlight information. Routine 180 is then complete. 
[0054] It should be appreciated that block 1 88 may re- 
quire the updating of multiple diagrams, e.g., if a partic- 
ular item is visible in more than one diagram. Moreover, 
it will be appreciated that a wide variety of selection or 
deselection input actions may be supported consistent 
with the invention. For example, similar to Windows- 
based selection features, it will be appreciated that dif- 
ferent selection actions, such as multiple select, area 
select, select all, etc., may be supported consistent with 
the invention. As an example, additional functions of ex- 
panding a selection in response to clicking on the items, 
with the shift or control key depressed on a keyboard 
may be used to selectively highlight multiple items in a 
pictorial representation. In other environments, a user 
may not be permitted to select or deselect certain items, 
with the selection of items being controlled exclusively 
by the filter criterion. Other modifications will be appar- 



ent to one of ordinary skill in the art. 
[0055] Fig. 7 next illustrates a focus routine 200 di- 
rected to a diagram, typically Initiated In response to us- 
er placement of a pointer within the visible area of a di- 

5 agram. Routine 200 begins in block 202 by determining 
which item is in focus based upon the item map associ- 
ated with the diagram. Block 204 determines whether 
such an item was found. If so, control passes to block 
206 to access the underlying hardware component to 

10 obtain status information therefor. 

[0056] Next, block 208 displays a pop-up with the sta- 
tus information obtained in block 206. It will be appreci- 
ated that the status information to be displayed within a 
pop-up will vary depending upon the type of hardware 

15 component. For example, as shown in Fig. 5, status in- 
formation such as the identity of the component and the 
active/inactive status of the component may be dis- 
played in a pop-up window 162. 

[0057] Returning to block 204, if no item is in the item 

20 map corresponding to the current position of the pointer, 
control passes to block 210 to remove any existing pop- 
up, whereby routine 200 is complete. 
[0058] Fig. 8 illustrates a display context menu routine 
220 directed to a diagram in response to user input di- 

25 reeled to that diagram. For example, routine 220 may 
be initiated in response to a user right-clicking on a par- 
ticular diagram, or in other manners known in the art. 
[0059] Routine 220 begins in block 222 by attempting 
to determine the item in the diagram to which the user 

30 input was directed, utilizing the item map defined in the 
diagram object. Block 224 determines whether such an 
item was found, and if not, passes control to block 226 
to display a default context menu associated with the 
diagram. If, however, a particular item was found, block 

35 2 24 passes control to block 228 to obtain the available 
actions from the item - typically accessing the underlying 
hardware component to retrieve a list of actions that may 
be performed with that item. Control then passes to 
block 230 to display the context menu with the available 

40 actions, as well as one or more default actions if so de- 
sired. Routine 220 is then complete. 
[0060] It will be appreciated that different types of 
hardware components may support a wide variety of dif- 
ferent types of actions, and as such, the ability to display 

45 a context-sensitive menu in association with a particular 
item provides an extremely flexible interface through 
which a user may perform a wide variety of management 
operations. As an example, for a disk unit, available ac- 
tions may include operations such as performing virus 

50 scans, formatting, de-fragmenting, activating, de-acti- 
vating, obtaining detailed status information, balancing, 
removing, replacing, compressing, grouping, reconfig- 
uring, moving, etc. For other types of items, e.g., net- 
work adaptors, many of such actions would be inappro- 

55 priate, and a different set of actions may be supported. 
Furthermore, implementation of a query interface 
through which a component manager could retrieve 
available actions from a component object would be well 
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within the abilities of one of ordinary skill in the art having 
the benefit of the instant disclosure. 
[0061] It will also be appreciated that the available ac- 
tions associated with multiple itenns may be polled in 
some instances and displayed on a context-sensitive s 
menu. For example, rather than displaying a default 
context menu for a diagram when no particular item is 
specified, the available actions for all items accessible 
via the diagram may be displayed in a context menu. 
The list of available actions for all such items may be io 
formatted as appropriate, e.g., to include only opera- 
tions that may be performed on all items, or to include 
within different sections of the menu actions that may 
be performed on all of the relevant items on a particular 
diagram. As an example, a menu option such as "format ^5 
all drives on this tower" may be displayed to a user 
[0062] Fig. 9 illustrates a perform action routine 240 
representing another supported functionality of compo- 
nent manager 42, that of performing a collective action 
on one or more hardware components via the pictorial 20 
representation. Routine 240 may be called in any 
number of situations, e.g., in response to selection of a 
menu item, depression of a toolbar button, selection of 
a context menu item, as well as keyboard input, and 
combinations thereof. 25 
[0063] Routine 240 begins in block 242 by invoking 
the requested action on all highlighted items. It will be 
appreciated that given the polymorphism supported by 
the object-oriented GUI framework described herein, 
the generic component object interface available to 30 
each item object will permit the requested action to be 
invoked on all selected items simply by searching 
through the GUI framework to identify highlighted items, 
and then invoking the appropriate action on the associ- 
ated hardware component(s). 35 
[0064] Once the requested action has been invoked, 
control passes to block 244 to optionally retrieve status 
information from all highlighted items based upon com- 
pletion of the performance of the action requested by 
the user. Next, block 246 updates any diagrams, if nec- 40 
essary, based upon the results of the requested action. 
Routine 240 is then complete. 

[0065] Fig. 10 illustrates, for example, the display of 
a context menu and the initiation of an action in the man- 
ner described above in connection with Figs. 8 and 9. 45 
In particular, assume forexample that a user right-clicks 
on item 1 56c with the pointer 1 60 positioned as illustrat- 
ed in Fig. 5. In response to such user input, a context 
menu appropriate for the item (here a disk unit) is dis- 
played as shown at164inFig.10.A variety of available so 
actions may be displayed to a user, including formatting 
the disk unit, formatting all selected disk units, perform- 
ing a virus scan operation on the unit or performing a 
virus scan on all of the selected units, among a wide 
variety of other component-appropriate actions. As fur- 55 
ther shown in Fig. 1 0, movement of pointer 1 60 over the 
"format selected units" item 166 on context menu 164 
will initiate a format operation on all of the selected items 



156a-156e represented in the pictorial representation. 
It should also be appreciated that, given the generic user 
interface, the selected disk units may be different types 
of disk drives, and in fact, each such unit could be pro- 
vided on a different type of computer platform. This 
would permit, for example, a format operation to be sub- 
mitted concurrently for disk units provided on multiple 
platforms, e.g., Windows NT servers, AS/400 midrange 
computers, RS/6000 Unix servers, etc. 
[0066] Various modifications may be made to the il- 
lustrated embodiments. Forexample. in some embodi- 
ments, additional information may be overlaid on a pic- 
torial representation. Diagnostic or error information 
may be displayed in association with a particular hard- 
ware component, e.g., via graphics, icons, animation 
and/or text. Such functionality could permit, for example, 
a system operator to be notified of failures via flashing 
representations of failed components. 

Claims 

1 . A method of managing computer hardware compo- 
nents, the method comprising: 

(a) displaying a pictorial representation on a 
computer display, the pictorial representation 
associated with a plurality of hardware compo- 
nents and representing a physical configuration 
of each of the plurality of hardware compo- 
nents; and 

(b) indicating a selected status for multiple 
hardware components from the plurality of 
hardware components within the pictorial rep- 
resentation associated with the plurality of 
hardware components. 

2. The method of claim 1 , wherein the pictorial repre- 
sentation includes a first diagram of at least one en- 
closure within which the plurality of hardware com- 
ponents is disposed, the diagram further depicting 
a physical location of each of the plurality of hard- 
ware components in the enclosure. 

3. The method of claim 2, wherein the first diagram 
depicts a first view of the enclosure taken from a 
first viewpoint, and wherein the pictorial represen- 
tation further includes a second diagram depicting 
a second view of the enclosure taken from a second 
viewpoint. 

4. The method of claim 2 or claim 3, wherein at least 
one of the plurality of hardware components com- 
prises an unused interface component configured 
to physically interconnect with another hardware 
component, the method further comprising manag- 
ing the unused interface component through user 
input directed to the pictorial representation. 
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5. The method of any one of the preceding claims, 
wherein each of the plurality of hardware compo- 
nents is associated with at least one attribute, the 
method further comprising: 

5 

(a) comparing attributes associated with the 
plurality of hardware components against a fil- 
ter criterion; and 

(b) selecting those hardware components as- io 
sociated with attributes that match the filter cri- 
terion. 

6. The method of claim 5, further comprising generat- 
ing the filter criterion responsive to user input. 

7. The method of claim 5, further comprising selecting 
the filter criterion from a plurality of predetermined 
filter criteria, each of the plurality of predetermined 
filter criteria associated with a predetermined view 20 
among a plurality of views. 

8. The method of any one of claims 5 to 7, wherein 
each hardware component is associated with a 
hardware type, and wherein the filter criterion iden- 25 
tifies a selected hardware type, wherein selecting 
those hardware components includes selecting 
those hardware components associated with the 
selected hardware type. 

30 

9. The method of any one of claims 5 to 8, further com- 
prising updating the indication of the selected status 
for at least one of the multiple hardware compo- 
nents responsive to selection of those hardware 
components associated with attributes that match 35 
the filter criterion. 

10. The method of any one of claims 5 to 9, wherein 
each of the plurality of hardware components is as- 
sociated with at least one of a plurality of diagrams, 40 
each of which depicting a physical location of at 
least one of the plurality of hardware components, 

the method further comprising displaying within the 
pictorial representation only those diagrams from 
the plurality of diagrams that depict the physical lo- 45 
cation of at least one hardware component having 
a selected status. 

11. The method of anyone of the preceding claims, fur- 
ther comprising visually highlighting those portions so 
of the pictorial representation that depict the phys- 
ical configurations of the multiple hardware compo- 
nents that have a selected status. 

12. The method of any one of the preceding claims, fur- 55 
ther comprising updating the status of a first hard- 
ware component among the plurality of hardware 
components to one of a selected and an unselected 



status responsive to user input directed to that por- 
tion of the pictorial representation that depicts the 
physical configuration of the first hardware compo- 
nent. 

1 3. The method of any one of the preceding claims, fur- 
ther comprising performing a management opera- 
tion on each of the multiple hardware components 
that have a selected status responsive to user input. 

14. The method of claim 13, wherein the multiple hard- 
ware components are physically located in a plural- 
ity of computers, wherein performing the manage- 
ment operation includes performing the manage- 
ment operation in each of the plurality of computers. 

15. The method of claim 14, wherein at least two of the 
plurality of computers utilize different types of com- 
puter platforms. 

16. The method of any one of the preceding claims, fur- 
ther comprising retrieving a list of available man- 
agement operations associated with a first hard- 
ware component among the plurality of hardware 
components In response to user input directed to 
that portion of the pictorial representation that de- 
picts the physical configuration of the first hardware 
component. 

17. The method of claim 16, wherein the user input in- 
cludes user input to open a context sensitive menu, 
the method further comprising: 

(a) displaying the list of available management 
operations within a context sensitive menu; and 

(b) initiating one of the available management 
operations on the first hardware component re- 
sponsive to user input directed to the context 
sensitive menu. 

18. The method of any one of the preceding claims, fur- 
ther comprising retrieving status information asso- 
ciated with a first hardware component among the 
plurality of hardware components in response to us- 
er input directed to that portion of the pictorial rep- 
resentation that depicts the physical configuration 
of the first hardware component. 

19. The method of claim 18, wherein the user input in- 
cludes locating a user-manipulated pointer over 
that portion of the pictorial representation that de- 
picts the physical configuration of the first hardware 
component, the method further comprising display- 
ing the retrieved status information within a pop-up 
window disposed proximate that portion of the pic- 
torial representation that depicts the physical con- 
figuration of the first hardware component. 
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20. The method of any one of the preceding claims, 
wherein displaying the pictorial representation and 
indicating the selected status are performed on a 
first computer, and wherein each of the plurality of 
hardware components is physically located in the 5 
first computer. 

21. The method of any one of claims 1 to 19, wherein 
displaying the pictorial representation and indicat- 
ing the selected status are performed on a first com- f o 
puter, and wherein at least a portion of the plurality 

of hardware components are physically located in 
a second computer in communication with the first 
computer. 

15 

22. The method of any one of the preceding claims, 
wherein each of the plurality of hardware compo- 
nents is disposed in a computer selected from the 
group consisting of a single- user computer, a multi- 
user computer, a clustered computer, a multi-unit 20 
computer, and combinations thereof. 

23. An apparatus, comprising: 

(a) a memory; and 25 

(b) a program resident in the memory and con- 
figured to display a pictorial representation on 
a computer display, the pictorial representation 
associated with a plurality of hardware compo- 3o 
nentsand representing a physical configuration 

of each of the plurality of hardware compo- 
nents, the program further configured to indi- 
cate a selected status for multiple hardware 
components from the plurality of hardware 35 
components within the pictorial representation 
associated with the plurality of hardware com- 
ponents. 

24. A program product, comprising: 40 

(a) a program configured to display a pictorial 
representation on a computer display, the pic- 
torial representation associated with a plurality 

of hardware components and representing a 45 
physical configuration of each of the plurality of 
hardware components, the program further 
configured to indicate a selected status for mul- 
tiple hardware components from the plurality of 
hardware components within the pictorial rep- so 
resentation associated with the plurality of 
hardware components; and 

(b) a signal bearing medium bearing the pro- 
gram. 55 

25. The program product of claim 24, wherein the signal 
bearing medium includes at least one of a recorda- 



ble medium and a transmission medium. 

26. A method of managing computer hardware compo- 
nents, the method comprising: 

(a) accessing a plurality of computers to identify 
a plurality of hardware components resident in 
the plurality of computers; 

(b) dynamically generating a pictorial represen- 
tation on a computer display, the pictorial rep- 
resentation associated with the plurality of com- 
puters and representing a physical configura- 
tion of each of the plurality of hardware compo- 
nents within the plurality of computers; and 

(b) performing at (east one management oper- 
ation on a first hardware component among the 
plurality of hardware components in response 
to user input directed to that portion of the pic- 
torial representation that represents the physi- 
cal configuration of the first hardware compo- 
nent. 

27. The method of claim 26, wherein each of the plural- 
ity of hardware components is associated with at 
least one attribute, and wherein each of the plurality 
of hardware components is associated with at least 
one of a plurality of diagrams, the method further 
comprising: 

(a) comparing attributes associated with the 
plurality of hardware components against a fil- 
ter criterion; and 

(b) selecting those hardware components as- 
sociated with attributes that match the filter cri- 
terion; 

wherein dynamically generating the pictorial repre- 
sentation includes displaying within the pictorial 
representation only those diagrams associated with 
the selected hardware components. 
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